Software component technologies, like CORBA and J2EE, provide software building blocks that allow developers to easily share and reuse code. Software components increase the reusability of software by enforcing usage through well-defined interfaces that, in their most common implementations, are automatically generated by vendor supplied tools. The CORBA standard, for example, defines interfaces in the Interface Definition Language (IDL) and the resulting definition creates a contract between the producer of the CORBA component and its consumer. The use of well-defined interfaces, coupled with technologies that provide introspection and other services, enforces good design and increases the reusability of software as a whole.
In addition to traditional software component technologies, networked software component technologies improve on the state of the art by making it possible to reuse software components over a network. Using network software tools, client and server code can be automatically generated from the interfaces of components. The resulting client code contains code to marshall calls made to the client class to the server class. The resulting server class contains both the implementation of the component and code to translate calls received from the client code to the corresponding calls in the implementation of the component. In this way, networked components allow client programs to call code that may be located on other machines in the network as if it was located on the local computer. This enables a distributed form of development in which producers of components publish components on a network and consumers reuse them to build applications.
Despite the advantages of networked components, networked component technology have not yet been widely adopted. The development of components can only be distributed to the degree that component technology can automatically locate a component that both performs the desired functionality and has an interface that a client can use. The CORBA and the J2EE specifications attempt to solve the problem by providing a naming service that can be used to look for a component by specifying its name and its method signature. Other technologies from companies like Hewlett Packard and organizations like the W3C allow programmers to specify the inheritance details of a component or its attributes. None of these methods, which are described in more detail in the prior art, have enabled the automatic reuse of software envisioned in the early days of computer science.
The prior art includes three distinct classes of inventions for finding components on a network. In the first class, a component reference work is created. In this approach, the component reference work might be an encyclopedia, a source list, a knowledge base, a database management system, or a catalog. In the second class, the search is facilitated by analyzing the components or information distributed with the components. This is done through the use of an information class that is distributed with the component, using keywords to analyze the components, or domain knowledge that looks at interrelationships between different software components. In the third and final class, the search is facilitated by specifying attributes or methods of the desired component.
The shortcoming of all of these approaches is that there is no guarantee that the component that is found will perform the action, have the methods, or contain the attributes the client is expecting. This shortcoming arises from the fact that the names of classes, methods, and attributes are not strictly tied to their definitions in object-oriented programming. As a result, the provider of a component has to guess the names of the class, methods, and attributes that the programmer writing the client program will want. The programmer writing the client program, in turn, has to guess the names that the provider of the component choose when implementing the component. Because this mutual guessing game seldom succeeds, most programmers who want to reuse a component have to manually lookup the names the producer has chosen for the class, its methods, and attributes.
The requirement for human intervention limits the utility of distributed components since it requires a manual process every time a software component is reused. The present invention enables the automatic assemblage of network components without human intervention through the cohesion of semantics and syntax. This cohesion guarantees that both the producer and consumer of a software component will agree on the names of the component, its properties, and behavior without any prior communication. This increases the reusability of software as a whole and enables disjoint groups of developers to collaborate in a distributed manner without needing to communicate with each other.